Secure computing environment

ABSTRACT

Methods and systems for providing secure computing environments. Features of the present invention use a plurality of integrated security controls to ensure security of a computing environment. More specifically, features of the present invention detect discrepancies between a node&#39;s behavior and a defined policy to identify and remedy malicious behavior.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Appl. No.62/172,389 entitled “Secure Computing Environment,” filed on Jun. 8,2015, and is related to U.S. patent application Ser. No. 14/085,493entitled “Cyber-Semantic Account Management System,” filed Nov. 20,2013, the entire contents of which are both hereby incorporated byreference.

TECHNICAL FIELD

The present invention generally relates to methods and systems forproviding secure computing environments and, more particularly, tomethods and systems for providing secure computing environments byintegrating security controls.

BACKGROUND

Institutions such as small-to-mid size (SMB) businesses have been underincreasing pressure to prevent and recover from cyberattacks.Cyberattacks generally involve hackers or other threat actorscompromising and installing malicious software on a host device.

Existing techniques that attempt to detect intrusion and maliciousactivity typically require the definition of rules manually beforemonitoring begins. Accordingly, this makes them difficult to use due tothe effort associated with manual rule definition and theirsusceptibility to zero-day attacks that do not match existing rule sets.

Many existing defensive cyber security technologies such as the HostBased Security System (HBSS) are based on the concept of agents that runon and secure a platform. These agents generally rely on signatures andbaseline behaviors to identify known threats. Once identified, agentsprevent these threats from executing. For example, HBSS manages variousaspects of host security (firewall and port restrictions, USB devicerestrictions, security auditing, and rogue device detection amongothers) and runs as a background process at all times.

However, agent-based systems, while effective at stopping attacks usingknown tools and exploits, do not adequately protect againstsophisticated zero day attacks and are easily circumvented by attackerswho modify existing threats to produce new (and therefore unknown)signatures or who exploit known weaknesses in the agents themselves.Additionally, these agents utilize policies focused on preventingdangerous behaviors from occurring such as isolating the threat. Thesepolicies are ill-suited to repair a comprised system after a problem hasoccurred.

Another drawback of agent-based systems is that agents consume valuableresources on their host machine, thereby reducing its responsiveness.This may be particularly burdensome in environments where many virtualendpoints reside on the same physical machine.

A need exists, therefore, for methods and systems for security thatovercome these disadvantages.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription section. This summary is not intended to identify or excludekey features or essential features of the claimed subject matter, nor isit intended to be used as an aid in determining the scope of the claimedsubject matter.

In one aspect, embodiments relate to a method for providing a securecomputing environment. The method includes defining at least one policyof prescribed behavior for at least one node in the environment;executing at least one process on at least one node in the environment;determining a discrepancy between the prescribed behavior of the atleast one node based on the at least one policy and actual behavior ofthe at least one node; and performing at least one remedial action basedupon the at least one policy upon determining the discrepancy betweenthe prescribed behavior of the at least one node and the actual behaviorof the at least one node.

In one embodiment, the at least one remedial action includes one or moreof restarting an exploited node within the environment and generating areport.

In one embodiment, the actual behavior of the at least one node includesdata regarding the actual behavior of the at least one node obtained inat least substantially real time.

In one embodiment, the actual behavior of the at least one node includesat least one of memory usage, a number of processes being executed, andprocessor load.

In one embodiment, the method further includes deriving at least onerule describing a behavior pattern of at least one node using adetermined discrepancy.

In one embodiment, the method further includes classifying the at leastone process as malicious or non-malicious based on the actual behaviorof the at least one node. The method may further include relocating asecond process from a first node to a second node in response to anattack upon the environment.

In one embodiment, the method further includes modifying an outgoingmessage from a second process to change an operating system identifieror an application identifier in the outgoing message.

In one embodiment, the method further includes changing an internetprotocol (IP) address of a node in the environment.

In one embodiment, the method further includes creating a transactionaldata set to accomplish a set of transactions; and comparing thetransactional data set to a reference data set after the process isexecuted on the at least one node to determine whether any changes weremade to the transactional data set.

In another aspect, embodiments relate to a secure computing system. Thesystem includes at least one node for executing at least one process;and a classification module configured to execute at least one processon at least one node in the environment; determine a discrepancy betweenthe prescribed behavior of the at least one node based on at least onepolicy of prescribed behavior and the actual behavior of the node; andperform at least one remedial action based upon the at least one policyupon determining the discrepancy between the prescribed behavior of theat least one node and the actual behavior of the at least one node.

In one embodiment, the at least one remedial action includes one or moreof restarting an exploited node within the environment and generating areport.

In one embodiment, the actual behavior of the at least one node includesdata regarding the actual behavior of the at least one node obtained inat least substantially real time.

In one embodiment, the actual behavior of the at least one node includesat least one of memory usage, a number of processes being executed, andprocessor load.

In one embodiment, the classification module is further configured toderive at least one rule describing a behavior pattern of at least onenode using a determined discrepancy.

In one embodiment, the classification module is further configured toclassify the first process as malicious or non-malicious based on thebehavior of the at least one node.

In one embodiment, the classification module is further configured torelocate a second process from a first node to a second node in responseto an attack upon the environment.

In one embodiment, the classification module is further configured tomodify an outgoing message from a second process to change an operatingsystem identifier or an application identifier in the outgoing message.

In one embodiment, the classification module is further configured tochange an internet protocol (IP) address of a node in the environment.

In one embodiment, the secure system is readily deployable to at leastone external enterprise system.

In yet another aspect, embodiments relate to a computer readable mediumcontaining computer-executable instructions for performing a method forproviding a secure computing environment. The medium includescomputer-executable instructions for defining at least one policy ofprescribed behavior for at least one node in the environment;computer-executable instructions for executing at least one process onat least one node in the environment; computer-executable instructionsfor determining a discrepancy between the prescribed behavior of the atleast one node based on the at least one policy and the actual behaviorof the at least one node; and computer-executable instructions forperforming at least one remedial action based on the at least one policyupon determining the discrepancy between the prescribed behavior of theat least one node and the actual behavior of the at least one node.

BRIEF DESCRIPTION OF DRAWINGS

Non-limiting and non-exhaustive embodiments of the invention aredescribed with reference to the following figures, wherein likereference numerals refer to like parts throughout the various viewsunless otherwise specified.

FIG. 1 depicts a secure computing environment in accordance with oneembodiment;

FIG. 2 depicts a secure computing module in accordance with oneembodiment;

FIG. 3 depicts a secure computing module in accordance with anotherembodiment;

FIG. 4 depicts the administrative module of FIG. 3 in accordance withone embodiment;

FIG. 5 depicts the virtual desktop application of FIG. 3 in accordancewith one embodiment;

FIG. 6 depicts a flowchart of a method of providing a secure computingenvironment using the threat detonation chamber of FIG. 3 in accordancewith one embodiment;

FIG. 7 depicts a user interface in accordance with one embodiment;

FIG. 8 depicts a flowchart of a method of providing a secure computingenvironment in accordance with one embodiment; and

FIG. 9 depicts a flowchart of a method of providing a secure computingenvironment in accordance with another embodiment.

DETAILED DESCRIPTION

Various embodiments are described more fully below with reference to theaccompanying drawings, which form a part hereof, and which show specificexemplary embodiments. However, the concepts of the present disclosuremay be implemented in many different forms and should not be construedas limited to the embodiments set forth herein; rather, theseembodiments are provided as part of a thorough and complete disclosure,to fully convey the scope of the concepts, techniques andimplementations of the present disclosure to those skilled in the art.Embodiments may be practiced as methods, systems or devices.Accordingly, embodiments may take the form of a hardware implementation,an entirely software implementation or an implementation combiningsoftware and hardware aspects. The following detailed description is,therefore, not to be taken in a limiting sense.

Reference in the specification to “one embodiment” or to “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiments is included in at least one exampleimplementation or technique in accordance with the present disclosure.The appearances of the phrase “in one embodiment” in various places inthe specification are not necessarily all referring to the sameembodiment.

Some portions of the description that follow are presented in terms ofsymbolic representations of operations on non-transient signals storedwithin a computer memory. These descriptions and representations areused by those skilled in the data processing arts to most effectivelyconvey the substance of their work to others skilled in the art. Suchoperations typically require physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical, magnetic or optical signals capable of being stored,transferred, combined, compared and otherwise manipulated. It isconvenient at times, principally for reasons of common usage, to referto these signals as bits, values, elements, symbols, characters, terms,numbers, or the like. Furthermore, it is also convenient at times, torefer to certain arrangements of steps requiring physical manipulationsof physical quantities as modules or code devices, without loss ofgenerality.

However, all of these and similar terms are to be associated with theappropriate physical quantities and are merely convenient labels appliedto these quantities. Unless specifically stated otherwise as apparentfrom the following discussion, it is appreciated that throughout thedescription, discussions utilizing terms such as “processing” or“computing” or “calculating” or “determining” or “displaying” or thelike, refer to the action and processes of a computer system, or similarelectronic computing device, that manipulates and transforms datarepresented as physical (electronic) quantities within the computersystem memories or registers or other such information storage,transmission or display devices. Portions of the present disclosureinclude processes and instructions that may be embodied in software,firmware or hardware, and when embodied in software, may be downloadedto reside on and be operated from different platforms used by a varietyof operating systems.

The present disclosure also relates to an apparatus for performing theoperations herein. This apparatus may be specially constructed for therequired purposes, or it may comprise a general-purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, any type ofdisk including floppy disks, optical disks, CD-ROMs, magnetic-opticaldisks, read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, application specific integratedcircuits (ASICs), or any type of media suitable for storing electronicinstructions, and each may be coupled to a computer system bus.Furthermore, the computers referred to in the specification may includea single processor or may be architectures employing multiple processordesigns for increased computing capability.

The processes and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general-purposesystems may also be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform one or more method steps. The structure for avariety of these systems is discussed in the description below. Inaddition, any particular programming language that is sufficient forachieving the techniques and implementations of the present disclosuremay be used. A variety of programming languages may be used to implementthe present disclosure as discussed herein.

In addition, the language used in the specification has been principallyselected for readability and instructional purposes and may not havebeen selected to delineate or circumscribe the disclosed subject matter.Accordingly, the present disclosure is intended to be illustrative, andnot limiting, of the scope of the concepts discussed herein.

Features of the present invention provide a secure computing environmentthat overcomes the disadvantages of existing techniques mentioned above.The secure computing module 106: (1) is decoupled from infrastructure onwhich protection mechanisms are executed; (2) is minimally invasive toexisting infrastructure; (3) requires minimal operator effort toconfigure and deploy; (4) works out-of-the-box with a large number ofplatforms; and (5) utilizes, to the maximum extent possible, existingprotocols, formats, and standards.

FIG. 1 illustrates a secure computing environment 100 in accordance withone embodiment. The environment may include a plurality of nodes N 102in operable connectivity via a network 104. In the context of thepresent application, the term “node” may refer to any type of device orlocation in which a virtual machine may be executed. These nodes N 102may each be encrypted to require hackers or other threat actors(hereinafter “threat actors”) to either break the cryptography to obtainaccess to data on any of the nodes N 102. The environment 100 alsoincludes one or more secure computing modules 106 configured with orotherwise in operable communication with the nodes N 102.

FIG. 2 illustrates a high-level overview of secure computing module 200(such as the secure computing module 106 of FIG. 1) in accordance withone embodiment. In this embodiment, the secure computing module 200 mayinclude a classification module 202 and a threat detonation chamber 204.Suspect files may be loaded into the threat detonation chamber 204 andprobed or executed in order to identify malicious activity. Anysuspicious activity may be logged and categorized by a logging module206. For example, an observed attempt by an executing suspect file toread a file and initiate an outgoing FTP transfer may be indicative ofan exfiltration attempt. Based on these observations during the testingstage, the classification module 202 may classify the file as maliciousor benign.

FIG. 3 illustrates the secure computing module 106 of FIG. 1 in moredetail. The secure computing module 106 may include an encrypted virtualappliance with a polymorphic attack surface (PAS) 302, an administrativemodule 304, and a virtual desktop application 306. Using thesecomponents, the secure computing module 106 implements several keysecurity controls that are integrated to form a single, secure computingmodule.

Features of the present invention therefore allow for the creation of adynamic model of how individual nodes interact with larger enterprisesystems over time in order to detect when unexpected and potentiallydangerous behaviors emerge, in contrast to existing techniques whichrely upon known threat signatures or known threat behavior heuristics.

The secure computing module 106 is not required to reside on anyindividual system within the enterprise. Rather, features of the presentinvention utilize an architecture distributed across an arbitrary numberof nodes and, as such, does not present a single point of failure. Thiscreates a cross-platform, low-cost, scalable, and decentralizedcapability orthogonal (and therefore complementary to) adefense-in-depth posture based on existing technologies such asantivirus software, firewalls, and code hardening suites.

The encrypted virtual appliance 302 includes a threat detonation chamber308 within which access to an application 310 is performed and alsoincludes a reference standard database 312. The threat detonationchamber 308 may output an activity report 314 describing the executionof the application 310. The encrypted virtual appliance 302 may alsoinclude a honeypot module 316.

The administrative module 304 is illustrated in more detail in FIG. 4and may contain several modules to offer cyber capabilities based onpolicy-defined rules to provide a secure computing environment. Thesemodules include, but are not limited to, a network mapping module 318, alog analysis module 320, a whitelist/blacklist (WL/BL) module 322, asecurity infrastructure and event management module (SIEM) 324, abehavioral pattern analysis (BPA) module 326, an unsecure dataidentification module 328, a data encryption module 330, a vulnerabilitymodule 332, a software analysis (and injection) module 334, and asimulation module 336.

The network mapping module 318 may be configured to map or otherwiseidentify all devices in a specific network intermittently orcontinuously. These devices may include, but are not limited to,smartphones, tablets PCs, laptops, and other types of hardware devicessuch as servers, routers, and connected endpoints. The network mappingmodule 318 may be configured to send out packets to hosts and create anetwork map based on the received response(s).

The network mapping module 318 may be in communication with thewhitelist/blacklist (WL/BL) module 322 which creates a list of permitted(accepted) devices. These devices maybe designated based on theiroperating system, MAC address, IP address, etc. This list may bedesigned to block non-approved devices from connecting to the network(and to other devices). Additionally, a user interface may enable a userto stop connections to devices that are not on the whitelist, or enablea user to add a certain device to the whitelist. The WL/BL module 322may additionally or alternatively create a blacklist explicitly definingnon-approved devices, such that any device on the blacklist isprohibited from connecting to the network and other devices.

The WL/BL module 322 may also create lists of permitted/non-permittedapplications. For example, the WL/BL module 322 may use processmonitoring tools on each device to determine what processes are runningon each device (e.g., in terms of specific versions and/orconfigurations). Additionally, a user interface may enable anadministrator to stop processes that are not on an “approvedapplications” list or that are on a “do not run” list, such as malware.The WL/BL module 322 may work in conjunction with file integritychecking procedures to identify new software that has been installed andthat existing software has not been modified.

The log analysis module 320 may be configured to track all activityoccurring on a node. This activity may include dates and times oflogging in and logging out of a network, as well as any communicationssent and received. Additionally, the log analysis module 320 maycorrelate logs from network devices, servers, databases, applications,or the like to provide an end-to-end view of users' transactions. Thelog analysis module 320 may support writing rules to network devices(e.g., firewalls, routers) to block packets and/or block and disconnectuser sessions.

Information logged by the log analysis module 320 may also includeweblog data such as IP address information, browsing history, downloaddata, and time information. Any desired amount of data may be logged.For example, the log analysis module 320 may use a day's worth of data,an hour of data, a week of data, a month of data, a year of data, etc.The log analysis module 320 may also use statistical analysis to analyzethe logged data. In one embodiment, statistical analysis may beperformed to obtain minimum, maximum, average, and standard deviationvalues for given set of data.

Data from log analysis modules 320 from various systems may beintegrated by the SIEM module 324 to correlate or otherwise validatelong-running transactions over various systems. This information may becommunicated to the BPA module 326 to, for example, identify anyanomalous behavior.

For example, the SIEM module 324 may aggregate and correlate logs acrossmultiple devices and applications on the network to provide insight intoat least data flow across a transaction or set of transactions. Thisinformation may be used to recognize vulnerabilities based ontransactions and network device logs. Additionally, the SIEM module 324may integrate data from multiple log analysis modules 320 into a singlelog format.

Data from log analysis modules 320 may be audited to verify compliancewith one or more policies over a plurality of transactions. For example,a business entity may have a policy that states “a separated employee oraffiliate will have their system access terminated within 8 hours ofseparation.” To ensure this policy is followed, there may be along-running transaction consisting of multiple processes. Theseprocesses may include the actual process of separating the employee,which may be performed by human resource personnel (e.g., user “HR1”),and the process of removing the separated employee's access to thesystem, which may be performed by IT personnel (e.g., user “ITSec2”).Accordingly, data from log analysis modules 320 of various systems maybe used to monitor this long-running transaction and ensure that thesecond process occurs within the timeframe specified by the policy afterthe completion of the first process.

The unsecure data identification module 326 may be configured to findunsecure data. For example, the unsecure data identification module 326may be configured to find unencrypted credit card numbers, payment cardindustry (PCI) numbers, social security numbers, bank account numbers,telephone numbers, health-related information, and more. To identify theunencrypted data, the unsecure data identification module 326 may relyon standard regular expression parsing techniques to find data thatconforms to lists (e.g., the Federal Reserve Bank list of ACH paymentIDS).

It follows that the data encryption module 330 may encrypt any data asneeded. For example, any data identified by the unsecure dataidentification module 328 may be subsequently encrypted by the dataencryption module 330.

The data encryption module 330 may also encrypt data based on userattributes. Certain users in a system may have privileges limiting whatthey can access. For example, some users may only have low-levelsecurity clearance that does not allow them to view or otherwise accesscertain data (e.g., data deemed confidential). As another example, ahuman resource employee may be able to view east coast employee data butnot west coast employee data. This prevents users without access to therequired certificate from seeing data encrypted with the certificate.

The vulnerability analysis module 332 may use third party tools todetect common vulnerabilities and exposures, as well as penetrationtools to test known threat actor attack patterns. Additionally, thevulnerability analysis module 332 may test hypothetical patterns. Forexample, security features of the present invention may be testedagainst possible attack vectors to determine their susceptibility tothese hypothetical attacks in the future. The vulnerability analysismodule 332 may also provide reports of any vulnerabilities, as well asreference materials to understand the potential for and consequence ofan attack and potential solutions.

For example, one example of a penetration tool to test a known attackpattern is the software analysis (and injection) module 334, which mayfind code-based security issues such as SQL vulnerabilities to an SQLinjection attack and single factor authentication. If any such issuesare found, the software analysis module 334 may apply any requiredsoftware changes to resolve the identified vulnerability.

Another example of a penetration tool is the simulation module 336,which may be configured to test a security plan by implementingsimulated attacks. For example, these simulated attacks may includepenetration testing to find additional vulnerabilities not detected bythe vulnerability analysis module 332. In one embodiment, for example,the simulation module 336 may send simulated phishing emails to users tofind users that need a refresher training on phishing concepts (i.e.,users who open the link in the email). The link in the email could thenopen a phishing refresher training course.

Although the administrative module 304 of FIG. 4 is illustrated withseveral modules, a given administrative module 304 may be configuredwith less than all modules 318-336. Additionally or alternatively, othertypes of security controls in addition to or in lieu of thoseillustrated in FIG. 4 may be used to provide a secure computingenvironment. As discussed below, the various modules may be implementedon a deployable appliance to gather information regarding a particularenterprise. Depending on the policies of the particular enterprise, oneor more of these modules 318-336 may or may not be included.

FIG. 5 illustrates the virtual desktop application 306 of FIG. 3 in moredetail. The virtual desktop application 306 provides another level ofsecurity control. The virtual desktop application 306 may be presentedto a user via a user interface of device such as a smartphone, tablet,PC, or laptop.

The virtual desktop application 306 may include one or more desktopapplications. For example, it may contain virtual machines for desktopapplications such as office tools 340, web browsing tools 342,application user interfaces 344, and administrative tools 346. Thiscompartmentalized approach enables, among other features, oneapplication to be compromised without affecting the othercompartmentalized applications.

Referring back to FIG. 3, a threat actor may attempt to executemalicious content on the virtual appliance 302. Incoming applicationssuch as these may be placed and executed in the threat detonationchamber 308. For example, FIG. 6 depicts a flowchart of a method 600 ofproviding a secure computing environment in accordance with oneembodiment using the threat detonation chamber 308.

In step 602 of method 600, data is loaded into the threat detonationchamber 308. This data may include a suspect file and may be loaded intothe threat detonation chamber 308 to be probed for malicious activity.Essentially, the threat chamber 308 creates a surrogate environment forthe monitored execution of a suspect application. The data may include areference transactional data set created to accomplish a set oftransactions, for example. As shown in FIG. 3, the threat detonationchamber 308 may include reference data 312 (or a subset of referencedata) from a production application and may include a copy of thesuspect application retrieved from a known software versioningrepository.

Step 604 involves receiving at least one modification to the data in thethreat detonation chamber 308. For example, a user may modify the datausing a suspect user application or a suspect application may executeautonomously and interact with the data.

Step 606 involves the optional step of receiving log files for modifiedsystems. For example, the threat detonation chamber 308 may retrieve logfiles from the systems such as database redo logs.

Step 608 involves providing a summary of changes made to the data. Thissummary may be presented to a user via a user interface, for example,and may include before and after versions of all reference data setrecords changed. The summary may be presented to a user in a “plainEnglish” format so that the user can readily and easily understand anychanges. This comparison, therefore, may provide a user with anopportunity to determine whether the changes are correct or whetherunauthorized changes were introduced into the reference data set.

Step 610 involves performing at least one remedial action. If changeswere detected in step 606 that were not made by the user (but instead bya third party, for example), the user simply rejects the changes and thesecure computing module 106 may perform at least one remedial action toprevent or otherwise mitigate the effects of the malicious activity.Accordingly, the module 106 may initiate a remedial action such asgenerating a human-readable report useful for system administrators,restarting the exploited virtual machine from an earlier checkpointstate, or issuing an alert to a system administrator.

If, on the other hand, the changes shown in step 608 are correct, themethod 600 may proceed to step 612 which involves applying thetransactions performed in the threat detonation chamber 308 to thereference standard data. In other words, the threat chamber 308 mayapply the transactions directly to the production application using thedatabase or filesystem transaction utilities once the changes arereviewed and approved.

Referring back to FIG. 3, the honeypot 316 may present a profile similarto an actual virtual machine while it actually executes a decoyapplication. If an attempt is made to access the honeypot 316 (e.g., bya threat actor who mistakenly believes the honeypot 316 is the “real”machine), the honeypot 316 may record and study the attack to learn itsbehavior to assist in defending against future attacks.

Threat actors such as hackers commonly initiate cyberattacks by firstmapping a network to learn about computers, IP addresses, and open portson the network. The threat actor is then able to determine computers ofinterest to attack (e.g., due to an identified vulnerability), and thenbegin a series of attacks on the identified computers using theidentified vulnerability.

The honeypot 316 may therefore assist in providing secure computingenvironments in at least three regards: (1) the honeypot 316 hidesimportant assets on the network by presenting as a decoy asset withsimilar attributes; (2) the honeypot 316 enables a user to monitor andlearn from the threat actor's actions so that the user can takecountermeasures to frustrate future attacks; and (3) the honeypot 316can monitor attack rates so that the network can be remapped, therebyinterrupting the threat actor's kill chain.

The secure computing module 106 may include one or more honeypots 316for protocols such as file transfer protocol (FTP), secure shell (SSH),simple network management protocol (SNMP), or the like. In variousembodiments, it is contemplated that a user interface may enable a userto configure the honeypot 316 they want to deploy by entering certainconfiguration parameters (i.e., parameters that cannot be discoveredfrom the environment) and then deploy the defined honeypotconfiguration.

Once deployed, the honeypot 316 may open one or more ports on a virtualserver. Real users are generally unaware of these systems, so thepolymorphic attack surface may assume that any user that connects withthe honeypot 316 is a threat actor intending to discover moreinformation about the secure computing module 106. The honeypot 316 maytherefore use aggressive logging to monitor actions of the user.

Threat actors commonly aim to avoid machines they deem to be honeypotsto prevent their techniques and identities from being discovered. Inaccordance with features of the invention, therefore, the encryptedappliance 302 may take steps to make a protected VM appear very similarto the honeypot 316. This increases the likelihood that the threat actorwill refrain from attacking the protected VM to avoid being identifiedand having their attack techniques compromised.

In one embodiment the secure computing module 106 may comprise a hybridof a host and honeypot by acting both as a legitimate computer and ahoneypot using unused ports. A threat actor may assume that thehigh-value protected host is actually a high risk honeypot.

This configuration enables a number of features, any combination ofwhich can be used to at least assist in securing computing environments.For example, the combined configuration of the computer and honeypotmay, for example, modify outgoing network packets to spoof the host'soperating system and application fingerprints (along with any other typeof identification information) to at least confuse the threat actor.

In addition to modifying outgoing communications, the secure computingmodule 106 may disguise or otherwise alter certain characteristics ofthe applications running on the protected hosts to reduce thepossibility of identifying the platform based on application-relatedpatterns. Additionally, the secure computing module 106 mayautomatically alter observable network characteristics of the protectedhost as needed (e.g., based on semantic policy guidelines).

In another embodiment, the secure computing module 106 may relocate aparticular operating system and/or application. For example, thevirtualized host (as well as virtual applications running thereon) maybe transferred to another machine to minimize the effectiveness ofcyberattacks. User settings and state information may be transferred tothe new location as well to minimize the effect of the transfer on auser.

In yet another embodiment, the secure computing module 106 may changethe IP address of the host, thereby making the host harder to target bythreat actors. Any resulting disruption to remote clients of servicesrunning on the host can at least be mitigated by using existing IPhopping schemes. For example, the secure computing module 106 may use acoordinating entity acting as an IP address directory for authenticatedusers. These operations can be carried out at specified time intervalsand/or when cyber reconnaissance attempts or attacks are recognized.

The secure computing module 106 may further be configured to initiateplatform service requests (PSRs). PSRs may be node-initiated actionsthat result in platform snapshots (i.e., information about the state ofa platform). PSRs may be initiated automatically at specified timeintervals or whenever requested by a user, for example. Or, if a threathas been detected, PSRs may be initiated at more frequent intervals.

Responses to PSRs may include information related to the state of anode. For example, a response may include information related to virtualmemory usage. Or, the response(s) may include information aboutindividual processes (e.g., the number of file handles used by a givenprocess). For example, if Node° is a UNIX platform, a PSR to Node0 fromMonitor0 may involve Monitor0 opening an SSH connection to Node0 andrequesting information about the current processor load and memoryfootprint on that machine. Or, if Node0 were a Windows® platform, thePSR to that machine could be achieved using the Windows ManagementInstrumentation (WMI) interface.

The response to a PSR may vary and depend on the information requestedby the PSR. The amount and type of information returned by a PSR may bereferred to as PSR granularity. For example, information such as therouting table from a remote machine or information about each threadrunning in each process, along with any open file handles owned by eachprocess may be referred to as “fine-grained” information. Thisinformation may be needed much less frequently than “coarse-grained”information, such as the number of running threads or connected remotemachines. The secure computing module 106 may issue PSRs and receiveplatform information from multiple remote nodes concurrently.

Features of the present invention are designed to integrate easily intoan existing enterprise architecture. This architecture may includearbitrarily complex heterogeneous systems including various flavors ofnetworked UNIX, Windows, and even virtualized or mobile platforms. Thevarious functions of the secure computing module 106 may be distributedacross a number of remote monitoring processes that may communicate viaexisting TCP/IP-based protocols. Each monitoring process is responsiblefor handling a subset of nodes in the network. These monitoringprocesses need not be deployed within the monitored network so long asthey have remote access permissions. Thus, the operational overhead ofinstalling the secure computing module 106 on existing enterprisenetworks is minimal and the secure computing module 106 can accommodatean arbitrarily large network simply by using more monitoring nodes.

Over time, data regarding various platforms and processes runningthereon may be merged into a model of how each platform behaves usingmachine learning and data mining techniques. These techniques maygeneralize the behavior of a given node by inductively extractingconstraints from behavior snapshots retrieved over time. Theseconstraints may be placed in a trained execution model (TEM) andcompared with new, observed behaviors. The newest monitoring data foreach node may be compared to TEMs to determine whether previously unseenand potentially problematic behavior has emerged on a system.

Accordingly, one innovation of the secure computing module 106 is thatrules describing normal behavior patterns are derived automatically fromlive data and in at least substantially real time. As mentionedpreviously, the secure computing module 106 may perform at least oneremedial action in accordance with a policy if problematic behavior hasemerged.

For example, the secure computing module 106 of FIG. 1 may beimplemented as a deployable appliance that provides security protectionfor institutions such as small and mid-size business entities. Thisappliance may simply be plugged into a network (without requiring an ITexpert) to start collecting information regarding the network (e.g.,what cyber policy items are in compliance and which ones are not).

Once the deployable appliance is connected with a network, a GUI maypresent a display to a user. For example, FIG. 7 depicts a userinterface 700 displaying information related to a security policy of anetwork. As shown, the interface 700 may display information regarding aparticular policy that is being enforced, whether that policy is beingviolated, and details of the violation.

FIG. 8 depicts a flowchart of a method 800 of providing a securecomputing environment in accordance with one embodiment. Step 802involves defining at least one policy of prescribed behavior for atleast one node in the environment. A policy may be as simple as“ensuring particular software patches are up to date,” for example. Thepolicies that are specified may of course vary and depend on a givenenterprise.

Step 804 involves executing at least one process on at least one node inthe environment. This process may be executed in a threat detonationchamber in operable connectivity with the node.

Step 806 involves determining a discrepancy between the prescribedbehavior of the at least one node based on the at least one policy andactual behavior of the at least one node. For example, certain changesmade to an application may suggest compromise by a third party. Or,attempts to initiate an outgoing FTP transfer may be indicative of anexfiltration attempt by a third party. Other types of behavior mayrelate to memory usage, a number of processes being executed, andprocessor load. These observations may represent discrepancies from theprescribed behavior of a node based on a policy, and informationregarding the node's behavior may be gathered intermittently orcontinuously and sometimes at least substantially in real time.

Step 808 involves performing at last one remedial action based upon theat least one policy upon determining the discrepancy between theprescribed behavior of the at least one node and the actual behavior ofthe at least one node. If certain discrepancies between the node'sactual behavior and the prescribed behavior based on a policy exist, thesecure computing module 106 may initiate at least one remedial action.For example, the secure computing module 106 may restart an exploitednode from an earlier checkpoint and/or generate a human-readable reportto inform a system administrator of the discrepancy.

In accordance with another embodiment, the remedial action may be torelocate a second process from a first node to a second node in responseto an attack upon the environment. For example, if an attack upon acomputing environment is detected, processes may be moved to a differentnode to at least mitigate the effect of any malicious processes.

In accordance with another embodiment, the remedial action may be tomodify an outgoing message from a second process to change an operatingsystem identifier or an application identifier in the outgoing message.These steps are essentially spoofing techniques to feed the attackerfalse information about the protected host, thereby at least confusingand frustrating the threat actor.

In yet another embodiment, the remedial action may be to change an IPaddress of a node in the environment. Changing the IP address of aparticular host may make it harder to target by threat actors, forexample.

The above mentioned remedial actions may introduce a level offalsification and dynamism to protect client and server hosts alike fromcyber-reconnaissance efforts. Additionally, these actions minimallyimpact legitimate users of systems.

FIG. 9 depicts a flowchart of a method 900 of providing a securecomputing environment in accordance with another embodiment. Steps 902,904, 906, and 908 are similar to steps 802, 804, 806, and 808 of FIG. 8,respectively, and are not repeated here.

Step 910 is optional and involves deriving at least one rule describinga behavior pattern of at least one node using a determined discrepancy.The at least one rule may be derived automatically from live data, andmay further be used to describe and/or enforce a policy in the future.

Step 912 is optional and involves classifying the at least one processas malicious or non-malicious based on the actual behavior of the atleast one node. Steps 910 and 912 may be performed in conjunction witheach other. For example, the rule generated in step 910 may be toprohibit future execution of a process that was classified as maliciousin step 912.

The methods, systems, and devices discussed above are examples. Variousconfigurations may omit, substitute, or add various procedures orcomponents as appropriate. For instance, in alternative configurations,the methods may be performed in an order different from that described,and that various steps may be added, omitted, or combined. Also,features described with respect to certain configurations may becombined in various other configurations. Different aspects and elementsof the configurations may be combined in a similar manner. Also,technology evolves and, thus, many of the elements are examples and donot limit the scope of the disclosure or claims.

Embodiments of the present disclosure, for example, are described abovewith reference to block diagrams and/or operational illustrations ofmethods, systems, and computer program products according to embodimentsof the present disclosure. The functions/acts noted in the blocks mayoccur out of the order as shown in any flowchart. For example, twoblocks shown in succession may in fact be executed substantiallyconcurrent or the blocks may sometimes be executed in the reverse order,depending upon the functionality/acts involved. Additionally, oralternatively, not all of the blocks shown in any flowchart need to beperformed and/or executed. For example, if a given flowchart has fiveblocks containing functions/acts, it may be the case that only three ofthe five blocks are performed and/or executed. In this example, any ofthe three of the five blocks may be performed and/or executed.

A statement that a value exceeds (or is more than) a first thresholdvalue is equivalent to a statement that the value meets or exceeds asecond threshold value that is slightly greater than the first thresholdvalue, e.g., the second threshold value being one value higher than thefirst threshold value in the resolution of a relevant system. Astatement that a value is less than (or is within) a first thresholdvalue is equivalent to a statement that the value is less than or equalto a second threshold value that is slightly lower than the firstthreshold value, e.g., the second threshold value being one value lowerthan the first threshold value in the resolution of the relevant system.

Specific details are given in the description to provide a thoroughunderstanding of example configurations (including implementations).However, configurations may be practiced without these specific details.For example, well-known circuits, processes, algorithms, structures, andtechniques have been shown without unnecessary detail in order to avoidobscuring the configurations. This description provides exampleconfigurations only, and does not limit the scope, applicability, orconfigurations of the claims. Rather, the preceding description of theconfigurations will provide those skilled in the art with an enablingdescription for implementing described techniques. Various changes maybe made in the function and arrangement of elements without departingfrom the spirit or scope of the disclosure.

Having described several example configurations, various modifications,alternative constructions, and equivalents may be used without departingfrom the spirit of the disclosure. For example, the above elements maybe components of a larger system, wherein other rules may takeprecedence over or otherwise modify the application of variousimplementations or techniques of the present disclosure. Also, a numberof steps may be undertaken before, during, or after the above elementsare considered.

Having been provided with the description and illustration of thepresent application, one skilled in the art may envision variations,modifications, and alternate embodiments falling within the generalinventive concept discussed in this application that do not depart fromthe scope of the following claims.

1. A method for providing a secure computing environment, the methodcomprising: identifying at least one software component of anapplication, wherein the at least one software component is selectedfrom the group consisting of a block of instructions, a method, a class,and a library of software components; identifying a vulnerabilityassociated with the at least one software component; identifying anacceptable repair strategy that addresses the vulnerability; andexecuting the identified repair strategy.
 2. The method of claim 1wherein the acceptable repair strategy is application-agnostic.
 3. Themethod of claim 1 wherein executing the identified repair strategyincludes modifying or removing one or more problematic softwarecomponents within the application.
 4. The method of claim 3 whereinexecuting the identified repair strategy further includes inserting atleast one new software component into the application.
 5. The method ofclaim 1 wherein executing the identified repair strategy includesredeploying the application without requiring recompilation orprogrammer involvement.
 6. The method of claim 1 wherein executing theidentified repair strategy includes modifying the application softwarecomponents in situ using runtime mechanisms.
 7. The method of claim 1wherein identifying the vulnerability associated with the at least onesoftware component includes identifying a violation of a mandate of apredefined policy.
 8. The method of claim 1 wherein identifying thevulnerability includes examining the application in a detonationchamber.
 9. A method for providing a secure computing environment, themethod comprising: receiving a file annotated with metadata; consultingthe metadata associated with the file prior to a process interactingwith the file to determine if the interaction would comply with apredetermined policy; examining the file in a detonation chamber beforethe interaction upon determining the interaction would not comply withthe predetermined policy; and performing at least one corrective actionafter examining the file in the detonation chamber.
 10. The method ofclaim 9 wherein the file is annotated with provenance data.
 11. Themethod of claim 9 wherein the detonation chamber includes a referencedata set, and examining the file in the detonation chamber includesexecuting the file autonomously to interact with the reference data. 12.The method of claim 11 further comprising receiving a summary of changesmade to the reference data.
 13. The method of claim 9 wherein performingthe at least one corrective action includes quarantining the file. 14.The method of claim 8 wherein performing the at least one correctiveaction includes issuing an alert. 15-21. (canceled)